-
Notifications
You must be signed in to change notification settings - Fork 154
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLD: Add CMake build using scikit-build-core #242
Conversation
I think I got every key from setup.py. The main difference is if the READTHEDOCS environment variable is set: I don't know how to change the dependencies based on that. On the other hand, given 3.8 is close to or past EOL, I suspect 3.3 is relatively uncommon, and the RTD install, without the unneeded bits, could be accomplished with pip install --no-deps.
…tes. numpy.distutils recommends setuptools<60, but that breaks pyproject.toml configuration. I like this way better. Still needs setup.py for the fortran module and for the Cheyenne configuration.
setuptools<60 just gets confused, and has no idea what the project name is. I just inverted that requirement: not sure if setuptools needs to be more recent still.
Works decently as a standalone builder/installer. Need to work on packaging for python. Scikit-build-core says it's a good option.
I should delete setup.py before too much longer, shouldn't I.
Pretty sure none of them are designed to be used that way. Also it kept CMake from trying to execute them with sh.
Can't test locally. Debating testing in my repo or draft PR.
It's not working, and I'd like to know why.
Only use my versions when skbuild isn't around.
It's not working, and it doesn't look easy to get working on Mac. Everything should be working now, so let's check.
Requirements list on RTD is much shorter than elsewhere, so do not install the extra packages on RTD. The last part of setup.py left is the Cheyenne configuration.
Thanks so much for your work here! I just noticed this and your prior PR. Admittedly, the maintenance on this package has been a struggle and difficult to prioritize. I'll try to take a look at these shortly. |
I started looking into this, but haven't been able to get it to build without error. I'm seeing something similar to what's showing up in CI. I'll try to take a deeper look soon as moving away from distutils is something I'd like to support / make happen. |
For some reason this isn't getting written despite every file being .f90 and no file being .f77, so put that in the code.
Update package metadata.
Let's see if this allows this to build. I haven't had problems locally with 3.9/1.26
This builds for me, but it fails to actually import at runtime for unclear reasons:
|
That's a new one. Usually it's complaining about the OpenMP symbols directly. Progress? On a related note, I think I should look into how to enable OpenMP, since I don't remember doing that. |
I made a reproduction example in a Docker container. Dockerfile:
|
I think I had it earlier, but deleted it from the link line because I thought the library was fixed-form only, rather than making sure it was available for the link line.
It appears that |
Let's see if that's the fix that broke the build
I think that issue is described here numpy/numpy#19161 , I tried adding a dummy function to trick this, but my fortran foo was not strong enough |
f2py seems to do better with those.
Mac doesn't call it ldd, not sure what it should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if these should be matched to the versions in CI as well, but it wouldn't hurt.
🎉 this is building for me locally now and passing tests. It looks like there are a few merge conflicts after the last PR was merged. @DWesl is this something you'd like to address or should I go ahead and do it? I'd like to take a bit more in depth look at the PR itself as well, but hopefully we can get this merged here soon. Thanks again for your work here! |
I haven't managed to test on Python 3.7, so I'm not sure if I should keep the Python>=3.7 requirement from Nor, for that matter, have I managed to test on Python 3.8, I think due to a different issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few suggestions here, mostly for consistency.
# TODO: Figure out the conditionals for running the C Preprocessor on Fortran files | ||
# I think the main thing to be changed is -E -cpp | ||
# Intel is -fpp -save-temps or /fpp on Windows | ||
# or call fpp instead of the fortran compiler to get it to stop after preprocessing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be good to look into this for Windows at least, but I think that can happen after getting this merged. Maybe along with some testing for Windows.
Don't specify Python version in CMakeLists.txt Co-authored-by: Katelyn FitzGerald <[email protected]>
Builds on pyproject.toml added in #241.